<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="kernel.html">Previous</A>
<A HREF="install.html">Next</A>
<HR>
<H1><A name="adv_config">Other configuration possibilities</A></H1>
<P>This document describes various options for FreeS/WAN configuration
 which are less used or more complex (often both) than the standard
 cases described in our<A href="config.html#config"> config</A> and<A href="quickstart.html#quick_guide">
 quickstart</A> documents.</P>
<H2><A name="thumb">Some rules of thumb about configuration</A></H2>
<H3><A name="cheap.tunnel">Tunnels are cheap</A></H3>
<P>Nearly all of the overhead in IPsec processing is in the encryption
 and authentication of packets. Our<A href="performance.html">
 performance</A> document discusses these overheads.</P>
<P>Beside those overheads, the cost of managing additional tunnels is
 trivial. Whether your gateway supports one tunnel or ten just does not
 matter. A hundred might be a problem; there is a<A href="performance.html#biggate">
 section</A> on this in the performance document.</P>
<P>So, in nearly all cases, if using multiple tunnels gives you a
 reasonable way to describe what you need to do, you should describe it
 that way in your configuration files.</P>
<P>For example, one user recently asked on a mailing list about this
 network configuration:</P>
<PRE>        netA---gwA---gwB---netB
                            |----netC

   netA and B are secured netC not.
   netA and gwA can not access netC</PRE>
<P>The user had constructed only one tunnel, netA to netB, and wanted to
 know how to use ip-route to get netC packets into it. This is entirely
 unnecessary. One of the replies was:</P>
<PRE>  The simplest way and indeed the right way to
  solve this problem is to set up two connections:

        leftsubnet=NetA
        left=gwA
        right=gwB
        rightsubnet=NetB
  and
        leftsubnet=NetA
        left=gwA
        right=gwB
        rightsubnet=NetC</PRE>
<P>This would still be correct even if we added nets D, E, F, ... to the
 above diagram and needed twenty tunnels.</P>
<P>Of course another possibility would be to just use one tunnel, with a
 subnet mask that includes both netB and netC (or B, C, D, ...). See
 next section.</P>
<P>In general, you can construct as many tunnels as you need. Networks
 like netC in this example that do not connect directly to the gateway
 are fine, as long as the gateway can route to them.</P>
<P>The number of tunnels can become an issue if it reaches 50 or so.
 This is discussed in the<A href="performance.html#biggate"> performance</A>
 document. Look there for information on supporting hundreds of Road
 Warriors from one gateway.</P>
<P>If you find yourself with too many tunnels for some reason like
 having eight subnets at one location and nine at another so you end up
 with 9*8=72 tunnels, read the next section here.</P>
<H3><A name="subnet.size">Subnet sizes</A></H3>
<P>The subnets used in<VAR> leftsubnet</VAR> and<VAR> rightsubnet</VAR>
 can be of any size that fits your needs, and they need not correspond
 to physical networks.</P>
<P>You adjust the size by changing the<A href="glossary.html#subnet">
 subnet mask</A>, the number after the slash in the subnet description.
 For example</P>
<UL>
<LI>in 192.168.100.0/24 the /24 mask says 24 bits are used to designate
 the network. This leave 8 bits to label machines. This subnet has 256
 addresses. .0 and .255 are reserved, so it can have 254 machines.</LI>
<LI>A subnet with a /23 mask would be twice as large, 512 addresses.</LI>
<LI>A subnet with a /25 mask would be half the size, 128 addresses.</LI>
<LI>/0 is the whole Internet</LI>
<LI>/32 is a single machine</LI>
</UL>
<P>As an example of using these in connection descriptions, suppose your
 company's head office has four physical networks using the address
 ranges:</P>
<DL>
<DT>192.168.100.0/24</DT>
<DD>development</DD>
<DT>192.168.101.0/24</DT>
<DD>production</DD>
<DT>192.168.102.0/24</DT>
<DD>marketing</DD>
<DT>192.168.103.0/24</DT>
<DD>administration</DD>
</DL>
<P>You can use exactly those subnets in your connection descriptions, or
 use larger subnets to grant broad access if required:</P>
<DL>
<DT>leftsubnet=192.168.100.0/24</DT>
<DD>remote hosts can access only development</DD>
<DT>leftsubnet=192.168.100.0/23</DT>
<DD>remote hosts can access development or production</DD>
<DT>leftsubnet=192.168.102.0/23</DT>
<DD>remote hosts can access marketing or administration</DD>
<DT>leftsubnet=192.168.100.0/22</DT>
<DD>remote hosts can access any of the four departments</DD>
</DL>
<P>or use smaller subnets to restrict access:</P>
<DL>
<DT>leftsubnet=192.168.103.0/24</DT>
<DD>remote hosts can access any machine in administration</DD>
<DT>leftsubnet=192.168.103.64/28</DT>
<DD>remote hosts can access only certain machines in administration.</DD>
<DT>leftsubnet=192.168.103.42/32</DT>
<DD>remote hosts can access only one particular machine in
 administration</DD>
</DL>
<P>To be exact, 192.68.103.64/28 means all addresses whose top 28 bits
 match 192.168.103.64. There are 16 of these because there are 16
 possibilities for the remainingg 4 bits. Their addresses are
 192.168.103.64 to 192.168.103.79.</P>
<P>Each connection description can use a different subnet if required.</P>
<P>It is possible to use all the examples above on the same FreeS/WAN
 gateway, each in a different connection description, perhaps for
 different classes of user or for different remote offices.</P>
<P>It is also possible to have multiple tunnels using different<VAR>
 leftsubnet</VAR> descriptions with the same<VAR> right</VAR>. For
 example, when the marketing manager is on the road he or she might have
 access to:</P>
<DL>
<DT>leftsubnet=192.168.102.0/24</DT>
<DD>all machines in marketing</DD>
<DT>192.168.101.32/29</DT>
<DD>some machines in production</DD>
<DT>leftsubnet=192.168.103.42/32</DT>
<DD>one particular machine in administration</DD>
</DL>
<P>This takes three tunnels, but tunnels are cheap. If the laptop is set
 up to build all three tunnels automatically, then he or she can access
 all these machines concurrently, perhaps from different windows.</P>
<H3><A name="example.more">Other network layouts</A></H3>
<P>Here is the usual network picture for a site-to-site VPN::</P>
<PRE>     Sunset==========West------------------East=========Sunrise
           local net       untrusted net       local net</PRE>
<P>and for the Road Warrior::</P>
<PRE>                                           telecommuter's PC or
                                           traveller's laptop
     Sunset==========West------------------East
         corporate LAN     untrusted net</PRE>
<P>Other configurations are also possible.</P>
<H4><A name="internet.subnet">The Internet as a big subnet</A></H4>
<P>A telecommuter might have:</P>
<PRE>     Sunset==========West------------------East ================= firewall --- the Internet
         home network      untrusted net        corporate network</PRE>
<P>This can be described as a special case of the general
 subnet-to-subnet connection. The subnet on the right is 0.0.0.0/0, the
 whole Internet.</P>
<P>West (the home gateway) can have its firewall rules set up so that
 only IPsec packets to East are allowed out. It will then behave as if
 its only connection to the world was a wire to East.</P>
<P>When machines on the home network need to reach the Internet, they do
 so via the tunnel, East and the corporate firewall. From the viewpoint
 of the Internet (perhaps of some EvilDoer trying to break in!), those
 home office machines are behind the firewall and protected by it.</P>
<H4><A name="wireless.config">Wireless</A></H4>
<P>Another possible configuration comes up when you do not trust the
 local network, either because you have very high security standards or
 because your are using easily-intercepted wireless signals.</P>
<P>Some wireless networks have built-in encryption called<A href="glossary.html#WEP">
 WEP</A>, but its security is dubious. It is a fairly common practice to
 use IPsec instead.</P>
<P>In this case, part of your network may look like this:</P>
<PRE>          West-----------------------------East == the rest of your network
     workstation   untrusted wireless net</PRE>
<P>Of course, there would likely be several wireless workstations, each
 with its own IPsec tunnel to the East gateway.</P>
<P>The connection descriptions look much like Road Warrior descriptions:</P>
<UL>
<LI>each workstation should have its own unique
<UL>
<LI>identifier for IPsec</LI>
<LI>RSA key</LI>
<LI>connection description.</LI>
</UL>
</LI>
<LI>on the gateway, use<VAR> left=%any</VAR>, or the workstation IP
 address</LI>
<LI>on workstations,<VAR> left=%defaultroute</VAR>, or the workstation
 IP address</LI>
<LI><VAR>leftsubnet=</VAR> is not used.</LI>
</UL>
<P>The<VAR> rightsubnet=</VAR> parameter might be set in any of several
 ways:</P>
<DL>
<DT>rightsubnet=0.0.0.0/0</DT>
<DD>allowing workstations to access the entire Internet (see<A href="#internet.subnet">
 above</A>)</DD>
<DT>rightsubnet=a.b.c.0/24</DT>
<DD>allowing access to your entire local network</DD>
<DT>rightsubnet=a.b.c.d/32</DT>
<DD>restricting the workstation to connecting to a particular server</DD>
</DL>
<P>Of course you can mix and match these as required. For example, a
 university might allow faculty full Internet access while letting
 student laptops connect only to a group of lab machines.</P>
<H2><A name="choose">Choosing connection types</A></H2>
<P>One choice you need to make before configuring additional connections
 is what type or types of connections you will use. There are several
 options, and you can use more than one concurrently.</P>
<H3><A name="man-auto">Manual vs. automatic keying</A></H3>
<P>IPsec allows two types of connections, with manual or automatic
 keying. FreeS/WAN starts them with commands such as:</P>
<PRE>        ipsec manual --up <VAR>name</VAR>
        ipsec auto --up <VAR>name</VAR></PRE>
<P>The difference is in how they are keyed.</P>
<DL>
<DT><A href="glossary.html#manual">Manually keyed</A> connections</DT>
<DD>use keys stored in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf</A>
.</DD>
<DT><A href="glossary.html#auto">Automatically keyed</A> connections</DT>
<DD>use keys automatically generated by the Pluto key negotiation
 daemon. The key negotiation protocol,<A href="glossary.html#IKE"> IKE</A>
, must authenticate the other system. (It is vulnerable to a<A href="glossary.html#middle">
 man-in-the-middle attack</A> if used without authentication.) We
 currently support two authentication methods:
<UL>
<LI>using shared secrets stored in<A href="manpage.d/ipsec.secrets.5.html">
 ipsec.secrets</A>.</LI>
<LI>RSA<A href="glossary.html#public"> public key</A> authentication,
 with our machine's private key in<A href="manpage.d/ipsec.secrets.5.html">
 ipsec.secrets</A>. Public keys for other machines may either be placed
 in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf</A> or provided via
 DNS.</LI>
</UL>
<P>A third method, using RSA keys embedded in<A href="glossary.html#X509">
 X.509</A> certtificates, is provided by user<A href="web.html#patch">
 patches</A>.</P>
</DD>
</DL>
<P><A href="glossary.html#manual">Manually keyed</A> connections provide
 weaker security than<A href="glossary.html#auto"> automatically keyed</A>
 connections. An opponent who reads ipsec.secrets(5) gets your
 encryption key and can read all data encrypted by it. If he or she has
 an archive of old messages, all of them back to your last key change
 are also readable.</P>
<P>With automatically-(re)-keyed connections, an opponent who reads
 ipsec.secrets(5) gets the key used to authenticate your system in IKE
 -- the shared secret or your private key, depending what authentication
 mechanism is in use. However, he or she does not automatically gain
 access to any encryption keys or any data.</P>
<P>An attacker who has your authentication key can mount a<A href="glossary.html#middle">
 man-in-the-middle attack</A> and, if that succeeds, he or she will get
 encryption keys and data. This is a serious danger, but it is better
 than having the attacker read everyting as soon as he or she breaks
 into ipsec.secrets(5).. Moreover, the keys change often so an opponent
 who gets one key does not get a large amount of data. To read all your
 data, he or she would have to do a man-in-the-middle attack at every
 key change.</P>
<P>We discuss using<A href="#prodman"> manual keying in production</A>
 below, but this is<STRONG> not recommended</STRONG> except in special
 circumstances, such as needing to communicate with some implementation
 that offers no auto-keyed mode compatible with FreeS/WAN.</P>
<P>Manual keying may also be useful for testing. There is some
 discussion of this in our<A href="faq.html#man4debug"> FAQ</A>.</P>
<H3><A name="auto-auth">Authentication methods for auto-keying</A></H3>
<P>The IKE protocol which Pluto uses to negotiate connections between
 gateways must use some form of authentication of peers. A gateway must
 know who it is talking to before it can create a secure connection. We
 support two basic methods for this authentication:</P>
<UL>
<LI>shared secrets, stored in<A href="manpage.d/ipsec.secrets.5.html">
 ipsec.secrets(5)</A></LI>
<LI>RSA authentication</LI>
</UL>
<P>There are, howver, several variations on the RSA theme, using
 different methods of managing the RSA keys:</P>
<UL>
<LI>our RSA private key in<A href="manpage.d/ipsec.secrets.5.html">
 ipsec.secrets(5)</A> with other gateways' public keys
<DL>
<DT>either</DT>
<DD>stored in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A></DD>
<DT>or</DT>
<DD>looked up via<A href="glossary.html#DNS"> DNS</A></DD>
</DL>
</LI>
<LI>authentication with<A href="glossary.html#x509"> x.509</A>
 certificates.; See our<A href="web.html#patch"> links section</A> for
 information on user-contributed patches for this.:</LI>
</UL>
<P>Public keys in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5</A>
) give a reasonably straightforward method of specifying keys for
 explicitly configured connections.</P>
<P>Putting public keys in DNS allows us to support<A href="glossary.html#carpediem">
 opportunistic encryption</A>. Any two FreeS/WAN gateways can provide
 secure communication, without either of them having any preset
 information about the other.</P>
<P>X.509 certificates may be required to interface to various<A href="glossary.html#PKI">
 PKI</A>s.</P>
<H3><A name="adv-pk">Advantages of public key methods</A></H3>
<P>Authentication with a<A href="glossary.html#public"> public key</A>
 method such as<A href="glossary.html#RSA"> RSA</A> has some important
 advantages over using shared secrets.</P>
<UL>
<LI>no problem of secure transmission of secrets
<UL>
<LI>A shared secret must be shared, so you have the problem of
 transmitting it securely to the other party. If you get this wrong, you
 have no security.</LI>
<LI>With a public key technique, you transmit only your public key. The
 system is designed to ensure that it does not matter if an enemy
 obtains public keys. The private key never leaves your machine.</LI>
</UL>
</LI>
<LI>easier management
<UL>
<LI>Suppose you have 20 branch offices all connecting to one gateway at
 head office, and all using shared secrets. Then the head office admin
 has 20 secrets to manage. Each of them must be kept secret not only
 from outsiders, but also from 19 of the branch office admins. The
 branch office admins have only one secret each to manage.
<P>If the branch offices need to talk to each other, this becomes
 problematic. You need another 20*19/2 = 190 secrets for
 branch-to-branch communication, each known to exactly two branches. Now
 all the branch admins have the headache of handling 20 keys, each
 shared with exactly one other branch or with head office.</P>
<P>For larger numbers of branches, the number of connections and secrets
 increases quadratically and managing them becomes a nightmare. A
 1000-gateway fully connected network needs 499,500 secrets, each known
 to exactly two players. There are ways to reduce this problem, for
 example by introducing a central key server, but these involve
 additional communication overheads, more administrative work, and new
 threats that must be carefully guarded against.</P>
</LI>
<LI>With public key techniques, the<EM> only</EM> thing you have to keep
 secret is your private key, and<EM> you keep that secret from everyone</EM>
.
<P>As network size increaes, the number of public keys used increases
 linearly with the number of nodes. This still requires careful
 administration in large applications, but is nothing like the disaster
 of a quadratic increase. On a 1000-gateway network, you have 1000
 private keys, each of which must be kept secure on one machine, and
 1000 public keys which must be distributed. This is not a trivial
 problem, but it is manageable.</P>
</LI>
</UL>
</LI>
<LI>does not require fixed IP addresses
<UL>
<LI>When shared secrets are used in IPsec, the responder must be able to
 tell which secret to use by looking at the IP address on the incoming
 packets. When the other parties do not have a fixed IP address to be
 identified by (for example, on nearly all dialup ISP connections and
 many cable or ADSL links), this does not work well -- all must share
 the same secret!</LI>
<LI>When RSA authentication is in use, the initiator can identify itself
 by name before the key must be determined. The responder then checks
 that the message is signed with the public key corresponding to that
 name.</LI>
</UL>
</LI>
</UL>
<P>There is also a disadvantage:</P>
<UL>
<LI>your private key is a single point of attack, extremely valuable to
 an enemy
<UL>
<LI>with shared secrets, an attacker who steals your ipsec.secrets file
 can impersonate you or try<A href="glossary.html#middle">
 man-in-the-middle</A> attacks, but can only attack connections
 described in that file</LI>
<LI>an attacker who steals your private key gains the chance to attack
 not only existing connections<EM> but also any future connections</EM>
 created using that key</LI>
</UL>
</LI>
</UL>
<P>This is partly counterbalanced by the fact that the key is never
 transmitted and remains under your control at all times. It is likely
 necessary, however, to take account of this in setting security policy.
 For example, you should change gateway keys when an administrator
 leaves the company, and should change them periodically in any case.</P>
<P>Overall, public key methods are<STRONG> more secure, more easily
 managed and more flexible</STRONG>. We recommend that they be used for
 all connections, unless there is a compelling reason to do otherwise.</P>
<H2><A name="prodsecrets">Using shared secrets in production</A></H2>
<P>Generally, public key methods are preferred for reasons given above,
 but shared secrets can be used with no loss of security, just more work
 and perhaps more need to take precautions.</P>
<P>What I call &quot;shared secrets&quot; are sometimes also called &quot;pre-shared
 keys&quot;. They are used only for for authentication, never for encryption.
 Calling them &quot;pre-shared keys&quot; has confused some users into thinking
 they were encryption keys, so I prefer to avoid the term..</P>
<P>If you are interoperating with another IPsec implementation, you may
 find its documentation calling them &quot;passphrases&quot;.</P>
<H3><A name="secrets">Putting secrets in ipsec.secrets(5)</A></H3>
<P>If shared secrets are to be used to<A href="glossary.html#authentication">
 authenticate</A> communication for the<A href="glossary.html#DH">
 Diffie-Hellman</A> key exchange in the<A href="glossary.html#IKE"> IKE</A>
 protocol, then those secrets must be stored in<VAR> /etc/ipsec.secrets</VAR>
. For details, see the<A href="manpage.d/ipsec.secrets.5.html">
 ipsec.secrets(5)</A> man page.</P>
<P>A few considerations are vital:</P>
<UL>
<LI>make the secrets long and unguessable. Since they need not be
 remembered by humans, very long ugly strings may be used. We suggest
 using our<A href="manpage.d/ipsec_ranbits.8.html"> ipsec_ranbits(8)</A>
 utility to generate long (128 bits or more) random strings.</LI>
<LI>transmit secrets securely. You have to share them with other
 systems, but you lose if they are intercepted and used against you. Use<A
href="glossary.html#PGP"> PGP</A>,<A href="glossary.html#SSH"> SSH</A>,
 hand delivery of a floppy disk which is then destroyed, or some other
 trustworthy method to deliver them.</LI>
<LI>store secrets securely, in root-owned files with permissions
 rw------.</LI>
<LI>limit sharing of secrets. Alice, Bob, Carol and Dave may all talk to
 each other, but only Alice and Bob should know the secret for an
 Alice-Bob link.</LI>
<LI><STRONG>do not share private keys</STRONG>. The private key for RSA
 authentication of your system is stored in<A href="manpage.d/ipsec.secrets.5.html">
 ipsec.secrets(5)</A>, but it is a different class of secret from the
 pre-shared keys used for the &quot;shared secret&quot; authentication. No-one but
 you should have the RSA private key.</LI>
</UL>
<P>Each line has the IP addresses of the two gateways plus the secret.
 It should look something like this:</P>
<PRE>        10.0.0.1 11.0.0.1 : PSK &quot;jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT&quot;</PRE>
<P><VAR>PSK</VAR> indicates the use of a<STRONG> p</STRONG>re-<STRONG>s</STRONG>
hared<STRONG> k</STRONG>ey. The quotes and the whitespace shown are
 required.</P>
<P>You can use any character string as your secret. For security, it
 should be both long and extremely hard to guess. We provide a utility
 to generate such strings,<A href="manpage.d/ipsec_ranbits.8.html">
 ipsec_ranbits(8)</A>.</P>
<P>You want the same secret on the two gateways used, so you create a
 line with that secret and the two gateway IP addresses. The
 installation process supplies an example secret, useful<EM> only</EM>
 for testing. You must change it for production use.</P>
<H3><A name="securing.secrets">File security</A></H3>
<P>You must deliver this file, or the relevant part of it, to the other
 gateway machine by some<STRONG> secure</STRONG> means.<EM> Don't just
 FTP or mail the file!</EM> It is vital that the secrets in it remain
 secret. An attacker who knew those could easily have<EM> all the data
 on your &quot;secure&quot; connection</EM>.</P>
<P>This file must be owned by root and should have permissions<VAR>
 rw-------</VAR>.</P>
<H3><A name="notroadshared">Shared secrets for road warriors</A></H3>
<P>You can use a shared secret to support a single road warrior
 connecting to your gateway, and this is a reasonable thing to do in
 some circumstances. Public key methods have advantages, discussed<A href="#choose">
 above</A>, but they are not critical in this case.</P>
<P>To do this, the line in ipsec.secrets(5) is something like:</P>
<PRE>        10.0.0.1 0.0.0.0 : PSK &quot;jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT&quot;</PRE>
 where the<VAR> 0.0.0.0</VAR> means that any IP address is acceptable.
<P><STRONG>For more than one road warrior, shared secrets are<EM> not</EM>
 recommended.</STRONG> If shared secrets are used, then when the
 responder needs to look up the secret, all it knows about the sender is
 an IP address. This is fine if the sender is at a fixed IP address
 specified in the config file. It is also fine if only one road warrior
 uses the wildcard<VAR> 0.0.0.0</VAR> address. However, if you have more
 than one road warrior using shared secret authentication, then they
 must all use that wildcard and therefore<STRONG> all road warriors
 using PSK autentication must use the same secret</STRONG>. Obviously,
 this is insecure.</P>
<P><STRONG>For multiple road warriors, use public key authentication.</STRONG>
 Each roadwarrior can then have its own identity (our<VAR> leftid=</VAR>
 or<VAR> rightid=</VAR> parameters), its own public/private key pair,
 and its own secure connection.</P>
<H2><A name="prodman">Using manual keying in production</A></H2>
<P>Generally,<A href="glossary.html#auto"> automatic keying</A> is
 preferred over<A href="glossary.html#manual"> manual keying</A> for
 production use because it is both easier to manage and more secure.
 Automatic keying frees the admin from much of the burden of managing
 keys securely, and can provide<A href="glossary.html#PFS"> perfect
 forward secrecy</A>. This is discussed in more detail<A href="#man-auto">
 above</A>.</P>
<P>However, it is possible to use manual keying in production if that is
 what you want to do. This might be necessary, for example, in order to
 interoperate with some device that either does not provide automatic
 keying or provides it in some version we cannot talk to.</P>
<P>Note that with manual keying<STRONG> all security rests with the keys</STRONG>
. If an adversary acquires your keys, you've had it. He or she can read
 everything ever sent with those keys, including old messages he or she
 may have archived.</P>
<P>You need to<STRONG> be really paranoid about keys</STRONG> if you're
 going to rely on manual keying for anything important.</P>
<UL>
<LI>keep keys in files with 600 permissions, owned by root</LI>
<LI>be extremely careful about security of your gateway systems. Anyone
 who breaks into a gateway and gains root privileges can get all your
 keys and read everything ever encrypted with those keys, both old
 messages he has archived and any new ones you may send.</LI>
<LI>change keys regularly. This can be a considerable bother, (and
 provides an excellent reason to consider automatic keying instead), but
 it is<EM> absolutely essential</EM> for security. Consider a manually
 keyed system in which you leave the same key in place for months:
<UL>
<LI>an attacker can have a very large sample of text sent with that key
 to work with. This makes various cryptographic attacks much more likely
 to succeed.</LI>
<LI>The chances of the key being compromised in some non-cryptographic
 manner -- a spy finds it on a discarded notepad, someone breaks into
 your server or your building and steals it, a staff member is bribed,
 tricked, seduced or coerced into revealing it, etc. -- also increase
 over time.</LI>
<LI>a successful attacker can read everything ever sent with that key.
 This makes any successful attack extremely damaging.</LI>
</UL>
 It is clear that you must change keys often to have any useful
 security. The only question is how often.</LI>
<LI>use<A href="glossary.html#PGP"> PGP</A> or<A href="glossary.html#SSH">
 SSH</A> for all key transfers</LI>
<LI>don't edit files with keys in them when someone can look over your
 shoulder</LI>
<LI>worry about network security; could someone get keys by snooping
 packets on the LAN between your X desktop and the gateway?</LI>
<LI>lock up your backup tapes for the gateway system</LI>
<LI>... and so on</LI>
</UL>
<P>Linux FreeS/WAN provides some facilities to help with this. In
 particular, it is good policy to<STRONG> keep keys in separate files</STRONG>
 so you can edit configuration information in /etc/ipsec.conf without
 exposing keys to &quot;shoulder surfers&quot; or network snoops. We support this
 with the<VAR> also=</VAR> and<VAR> include</VAR> syntax in<A href="manpage.d/ipsec.conf.5.html">
 ipsec.conf(5)</A>.</P>
<P>See the last example in our<A href="examples"> examples</A> file. In
 the /etc/ipsec.conf<VAR> conn samplesep</VAR> section, it has the line:</P>
<PRE>        also=samplesep-keys</PRE>
<P>which tells the &quot;ipsec manual&quot; script to insert the configuration
 description labelled &quot;samplesep-keys&quot; if it can find it. The
 /etc/ipsec.conf file must also have a line such as:</P>
<PRE>include ipsec.*.conf</PRE>
<P>which tells it to read other files. One of those other files then
 might contain the additional data:</P>
<PRE>conn samplesep-keys
  spi=0x200
  esp=3des-md5-96
  espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
  espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf</PRE>
<P>The first line matches the label in the &quot;also=&quot; line, so the indented
 lines are inserted. The net effect is exactly as if the inserted lines
 had occurred in the original file in place of the &quot;also=&quot; line.</P>
<P>Variables set here are:</P>
<DL>
<DT>spi</DT>
<DD>A number needed by the manual keying code. Any 3-digit hex number
 will do, but if you have more than one manual connection then<STRONG>
 spi must be different</STRONG> for each connection.</DD>
<DT>esp</DT>
<DD>Options for<A href="glossary.html#ESP"> ESP</A> (Encapsulated
 Security Payload), the usual IPsec encryption mode. Settings here are
 for<A href="glossary.html#encryption"> encryption</A> using<A href="glossary.html#3DES">
 triple DES</A> and<A href="glossary.html#authentication">
 authentication</A> using<A href="glossary.html#MD5"> MD5</A>. Note that
 encryption without authentication should not be used; it is insecure.</DD>
<DT>espenkey</DT>
<DD>Key for ESP encryption. Here, a 192-bit hex number for triple DES.</DD>
<DT>espauthkey</DT>
<DD>Key for ESP authentication. Here, a 128-bit hex number for MD5.</DD>
</DL>
<P><STRONG>Note</STRONG> that the<STRONG> example keys we supply</STRONG>
 are intended<STRONG> only for testing</STRONG>. For real use, you
 should go to automatic keying. If that is not possible, create your own
 keys for manual mode and keep them secret</P>
<P>Of course, any files containing keys<STRONG> must</STRONG> have 600
 permissions and be owned by root.</P>
<P>If you connect in this way to multiple sites, we recommend that you
 keep keys for each site in a separate file and adopt some naming
 convention that lets you pick them all up with a single &quot;include&quot; line.
 This minimizes the risk of losing several keys to one error or attack
 and of accidentally giving another site admin keys which he or she has
 no business knowing.</P>
<P>Also note that if you have multiple manually keyed connections on a
 single machine, then the<VAR> spi</VAR> parameter must be different for
 each one. Any 3-digit hex number is OK, provided they are different for
 each connection. We reserve the range 0x100 to 0xfff for manual
 connections. Pluto assigns SPIs from 0x1000 up for automatically keyed
 connections.</P>
<P>If<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> contains
 keys for manual mode connections, then it too must have permissions<VAR>
 rw-------</VAR>. We recommend instead that, if you must manual keying
 in production, you keep the keys in separate files.</P>
<P>Note also that<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf</A>
 is installed with permissions<VAR> rw-r--r--</VAR>. If you plan to use
 manually keyed connections for anything more than initial testing, you<B>
 must</B>:</P>
<UL>
<LI>either change permissions to<VAR> rw-------</VAR></LI>
<LI>or store keys separately in secure files and access them via include
 statements in<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf</A>.</LI>
</UL>
<P>We recommend the latter method for all but the simplest
 configurations.</P>
<H3><A name="ranbits">Creating keys with ranbits</A></H3>
<P>You can create new<A href="glossary.html#random"> random</A> keys
 with the<A href="manpage.d/ipsec_ranbits.8.html"> ranbits(8)</A>
 utility. For example, the commands:</P>
<PRE>      umask 177
      ipsec ranbits 192  &gt; temp
      ipsec ranbits 128 &gt;&gt; temp</PRE>
<P>create keys in the sizes needed for our default algorithms:</P>
<UL>
<LI>192-bit key for<A href="glossary.html#3DES"> 3DES</A> encryption
<BR> (only 168 bits are used; parity bits are ignored)</LI>
<LI>128-bit key for keyed<A href="glossary.html#MD5"> MD5</A>
 authentication</LI>
</UL>
<P>If you want to use<A href="glossary.html#SHA"> SHA</A> instead of<A href="glossary.html#MD5">
 MD5</A>, that requires a 160-bit key</P>
<P>Note that any<STRONG> temporary files</STRONG> used must be kept<STRONG>
 secure</STRONG> since they contain keys. That is the reason for the
 umask command above. The temporary file should be deleted as soon as
 you are done with it. You may also want to change the umask back to its
 default value after you are finished working on keys.</P>
<P>The ranbits utility may pause for a few seconds if not enough entropy
 is available immediately. See ipsec_ranbits(8) and random(4) for
 details. You may wish to provide some activity to feed entropy into the
 system. For example, you might move the mouse around, type random
 characters, or do<VAR> du /usr &gt; /dev/null</VAR> in the background.</P>
<H2><A name="boot">Setting up connections at boot time</A></H2>
<P>You can tell the system to set up connections automatically at boot
 time by putting suitable stuff in /etc/ipsec.conf on both systems. The
 relevant section of the file is labelled by a line reading<VAR> config
 setup</VAR>.</P>
<P>Details can be found in the<A href="manpage.d/ipsec.conf.5.html">
 ipsec.conf(5)</A> man page. We also provide a file of<A href="examples">
 example configurations</A>.</P>
<P>The most likely options are something like:</P>
<DL>
<DT>interfaces=&quot;ipsec0=eth0 ipsec1=ppp0&quot;</DT>
<DD>Tells KLIPS which interfaces to use. Up to four interfaces numbered
 ipsec[0-3] are supported. Each interface can support an arbitrary
 number of tunnels.
<P>Note that for PPP, you give the ppp[0-9] device name here, not the
 underlying device such as modem (or eth1 if you are using PPPoE).</P>
</DD>
<DT>interfaces=%defaultroute</DT>
<DD>Alternative setting, useful in simple cases. KLIPS will pick up both
 its interface and the next hop information from the settings of the
 Linux default route.</DD>
<DT>forwardcontrol=no</DT>
<DD>Normally &quot;no&quot;. Set to &quot;yes&quot; if the IP forwarding option is disabled
 in your network configuration. (This can be set as a kernel
 configuration option or later. e.g. on Redhat, it's in
 /etc/sysconfig/network and on SuSE you can adjust it with Yast.) Linux
 FreeS/WAN will then enable forwarding when starting up and turn it off
 when going down. This is used to ensure that no packets will be
 forwarded before IPsec comes up and takes control.</DD>
<DT>syslog=daemon.error</DT>
<DD>Used in messages to the system logging daemon (syslogd) to specify
 what type of software is sending the messages. If the settings are
 &quot;daemon.error&quot; as in our example, then syslogd treats the messages as
 error messages from a daemon.
<P>Note that<A href="glossary.html#Pluto"> Pluto</A> does not currently
 pay attention to this variable. The variable controls setup messages
 only.</P>
</DD>
<DT>klipsdebug=</DT>
<DD>Debug settings for<A href="glossary.html#KLIPS"> KLIPS</A>.</DD>
<DT>plutodebug=</DT>
<DD>Debug settings for<A href="glossary.html#Pluto"> Pluto</A>.</DD>
<DT>... for both the above DEBUG settings</DT>
<DD>Normally, leave empty as shown above for no debugging output.
<BR> Use &quot;all&quot; for maximum information.
<BR> See ipsec_klipsdebug(8) and ipsec_pluto(8) man page for other
 options. Beware that if you set /etc/ipsec.conf to enable debug output,
 your system's log files may get large quickly.</DD>
<DT>dumpdir=/safe/directory</DT>
<DD>Normally, programs started by ipsec setup don't crash. If they do,
 by default, no core dump will be produced because such dumps would
 contain secrets. If you find you need to debug such crashes, you can
 set dumpdir to the name of a directory in which to collect the core
 file.</DD>
<DT>manualstart=</DT>
<DD>List of manually keyed connections to be automatically started at
 boot time. Useful for testing, but not for long term use. Connections
 which are automatically started should also be automatically re-keyed.</DD>
<DT>pluto=yes</DT>
<DD>Whether to start<A href="glossary.html#Pluto"> Pluto</A> when ipsec
 startup is done.
<BR> This parameter is optional and defaults to &quot;yes&quot; if not present.
<P>&quot;yes&quot; is strongly recommended for production use so that the keying
 daemon (Pluto) will automatically re-key the connections regularly. The
 ipsec-auto parameters ikelifetime, ipseclifetime and reykeywindow give
 you control over frequency of rekeying.</P>
</DD>
<DT>plutoload=&quot;reno-van reno-adam reno-nyc&quot;</DT>
<DD>List of tunnels (by name, e.g. fred-susan or reno-van in our
 examples) to be loaded into Pluto's internal database at startup. In
 this example, Pluto loads three tunnels into its database when it is
 started.
<P>If plutoload is &quot;%search&quot;, Pluto will load any connections whose
 description includes &quot;auto=add&quot; or &quot;auto=start&quot;.</P>
</DD>
<DT>plutostart=&quot;reno-van reno-adam reno-nyc&quot;</DT>
<DD>List of tunnels to attempt to negotiate when Pluto is started.
<P>If plutostart is &quot;%search&quot;, Pluto will start any connections whose
 description includes &quot;auto=start&quot;.</P>
<P>Note that, for a connection intended to be permanent,<STRONG> both
 gateways should be set try to start</STRONG> the tunnel. This allows
 quick recovery if either gateway is rebooted or has its IPsec
 restarted. If only one gateway is set to start the tunnel and the other
 gateway restarts, the tunnel may not be rebuilt.</P>
</DD>
<DT>plutowait=no</DT>
<DD>Controls whether Pluto waits for one tunnel to be established before
 starting to negotiate the next. You might set this to &quot;yes&quot;
<UL>
<LI>if your gateway is a very limited machine and you need to conserve
 resources.</LI>
<LI>for debugging; the logs are clearer if only one connection is
 brought up at a time</LI>
</UL>
 For a busy and resource-laden production gateway, you likely want &quot;no&quot;
 so that connections are brought up in parallel and the whole process
 takes less time.</DD>
</DL>
<P>The example assumes you are at the Reno office and will use IPsec to
 Vancouver, New York City and Amsterdam.</P>
<H2><A name="multitunnel">Multiple tunnels between the same two gateways</A>
</H2>
<P>Consider a pair of subnets, each with a security gateway, connected
 via the Internet:</P>
<PRE>         192.168.100.0/24           left subnet
              |
         192.168.100.1
         North Gateway
         101.101.101.101            left
              |
         101.101.101.1              left next hop
         [Internet]
         202.202.202.1              right next hop
              |
         202.202.202.202            right
         South gateway
         192.168.200.1
              |
         192.168.200.0/24           right subnet</PRE>
<P>A tunnel specification such as:</P>
<PRE>conn northnet-southnet
      left=101.101.101.101
      leftnexthop=101.101.101.1
      leftsubnet=192.168.100.0/24
      leftfirewall=yes
      right=202.202.202.202
      rightnexthop=202.202.202.1
      rightsubnet=192.168.200.0/24
      rightfirewall=yes</PRE>
 will allow machines on the two subnets to talk to each other. You might
 test this by pinging from polarbear (192.168.100.7) to penguin
 (192.168.200.5).
<P>However,<STRONG> this does not cover other traffic you might want to
 secure</STRONG>. To handle all the possibilities, you might also want
 these connection descriptions:</P>
<PRE>conn northgate-southnet
      left=101.101.101.101
      leftnexthop=101.101.101.1
      right=202.202.202.202
      rightnexthop=202.202.202.1
      rightsubnet=192.168.200.0/24
      rightfirewall=yes

conn northnet-southgate
      left=101.101.101.101
      leftnexthop=101.101.101.1
      leftsubnet=192.168.100.0/24
      leftfirewall=yes
      right=202.202.202.202
      rightnexthop=202.202.202.1</PRE>
<P>Without these, neither gateway can do IPsec to the remote subnet.
 There is no IPsec tunnel or eroute set up for the traffic.</P>
<P>In our example, with the non-routable 192.168.* addresses used,
 packets would simply be discarded. In a different configuration, with
 routable addresses for the remote subnet,<STRONG> they would be sent
 unencrypted</STRONG> since there would be no IPsec eroute and there
 would be a normal IP route.</P>
<P>You might also want:</P>
<PRE>conn northgate-southgate
      left=101.101.101.101
      leftnexthop=101.101.101.1
      right=202.202.202.202
      rightnexthop=202.202.202.1</PRE>
<P>This is required if you want the two gateways to speak IPsec to each
 other.</P>
<P>This requires a lot of duplication of details. Judicious use of<VAR>
 also=</VAR> and<VAR> include</VAR> can reduce this problem.</P>
<P>Note that, while FreeS/WAN supports all four tunnel types, not all
 implementations do. In particular, some versions of Windows 2000 and
 the freely downloadable version of PGP provide only &quot;client&quot;
 functionality. You cannot use them as gateways with a subnet behind
 them. To get that functionality, you must upgrade to Windows 2000
 server or the commercially available PGP products.</P>
<H3><A name="advroute">One tunnel plus advanced routing</A></H3>
 It is also possible to use the new routing features in 2.2 and later
 kernels to avoid most needs for multple tunnels. Here is one mailing
 list message on the topic:
<PRE>Subject: Re: linux-ipsec: IPSec packets not entering tunnel?
   Date: Mon, 20 Nov 2000
   From: Justin Guyett &lt;jfg@sonicity.com&gt;

On Mon, 20 Nov 2000, Claudia Schmeing wrote:

&gt; Right                                                         Left
&gt;                      &quot;home&quot;                &quot;office&quot;
&gt; 10.92.10.0/24 ---- 24.93.85.110 ========= 216.175.164.91 ---- 10.91.10.24/24
&gt;
&gt; I've created all four tunnels, and can ping to test each of them,
&gt; *except* homegate-officenet.

I keep wondering why people create all four tunnels.  Why not route
traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
And 99% of the time you don't need to access &quot;office&quot; directly, which
means you can eliminate all but the subnet&lt;-&gt;subnet connection.</PRE>
 and FreeS/WAN technical lead Henry Spencer's comment:
<PRE>&gt; I keep wondering why people create all four tunnels.  Why not route
&gt; traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?

This is feasible, given some iproute2 attention to source addresses, but
it isn't something we've documented yet... (partly because we're still
making some attempt to support 2.0.xx kernels, which can't do this, but
mostly because we haven't caught up with it yet).

&gt; And 99% of the time you don't need to access &quot;office&quot; directly, which
&gt; means you can eliminate all but the subnet&lt;-&gt;subnet connection.

Correct in principle, but people will keep trying to ping to or from the
gateways during testing, and sometimes they want to run services on the
gateway machines too.</PRE>

<!-- Is this in the right spot in this document? -->
<H2><A name="opp.gate">An Opportunistic Gateway</A></H2>
<H3><A NAME="14_7_1">Start from full opportunism</A></H3>
<P>Full opportunism allows you to initiate and receive opportunistic
 connections on your machine. The remaining instructions in this section
 assume you have first set up full opportunism on your gateway using<A HREF="quickstart.html#opp.incoming">
 these instructions</A>. Both sets of instructions require mailing DNS
 records to your ISP. Collect DNS records for both the gateway (above)
 and the subnet nodes (below) before contacting your ISP.</P>
<H3><A NAME="14_7_2">Reverse DNS TXT records for each protected machine</A>
</H3>
<P>You need these so that your Opportunistic peers can:</P>
<UL>
<LI>discover the gateway's address, knowing only the IP address that
 packets are bound for</LI>
<LI>verify that the gateway is authorised to encrypt for that endpoint</LI>
</UL>
<P>On the gateway, generate a TXT record with:</P>
<PRE>    ipsec showhostkey --txt 192.0.2.11</PRE>
<P>Use your gateway address in place of 192.0.2.11.</P>
<P>You should see (keys are trimmed for clarity throughout our example):</P>
<PRE>    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;</PRE>
<P><B>This MUST BE the same key as in your gateway's TXT record, or
 nothing will work.</B></P>
<P>In a text file, make one copy of this TXT record for each subnet
 node:</P>
<PRE>    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;
                                                                                
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;
                                                                                
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;</PRE>
<P>Above each entry, insert a line like this:</P>
<PRE>    98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.</PRE>
<P>It must include:</P>
<UL>
<LI>The subnet node's address in reverse map format. For example,
 192.0.2.120 becomes<VAR> 120.2.0.192.in-addr.arpa.</VAR>. Note the
 final period.</LI>
<LI><VAR>IN PTR</VAR></LI>
<LI>The node's name, ie.<VAR> arthur.example.com.</VAR>. Note the final
 period.</LI>
</UL>
<P>The result will be a file of TXT records, like this:</P>
<PRE>    98.2.0.192.in-addr.arpa. IN PTR arthur.example.com.
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;
                                                                                
    99.2.0.192.in-addr.arpa. IN PTR ford.example.com.
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;
                                                                                
    100.2.0.192.in-addr.arpa. IN PTR trillian.example.com.
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  &quot;X-IPsec-Server(10)=192.0.2.11&quot; &quot; AQOF8tZ2...+buFuFn/&quot;</PRE>
<H3><A NAME="14_7_3">Publish your records</A></H3>
<P>Ask your ISP to publish all the reverse DNS records you have
 collected. There may be a delay of up to 48 hours as the records
 propagate.</P>
<H3><A NAME="14_7_4">...and test them</A></H3>
<P>Check a couple of records with commands like this one:</P>
<PRE>    ipsec verify --host ford.example.com
    ipsec verify --host trillian.example.com</PRE>
<P>The<VAR> verify</VAR> command checks for TXT records for both the
 subnet host and its gateway. You should see output like:</P>
<PRE>    ...
    Looking for TXT in reverse map: 99.2.0.192.in-addr.arpa [OK]
    ...
    Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa   [OK]
    ...
    Looking for TXT in reverse map: 100.2.0.192.in-addr.arpa [OK]
    ...
    Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa   [OK]
    ...</PRE>
<H3><A NAME="14_7_5">No Configuration Needed</A></H3>
<P>FreeS/WAN 2.x ships with a built-in, automatically enabled OE
 connection<VAR> conn packetdefault</VAR> which applies OE, if possible,
 to all outbound traffic routed through the FreeS/WAN box. The<A HREF="manpage.d/ipsec.conf.5.html">
 ipsec.conf(5) manual</A> describes this connection in detail. While the
 effect is much the same as<VAR> private-or-clear</VAR>, the
 implementation is different: notably, it does not use policy groups.</P>
<P>You can create more complex OE configurations for traffic forwarded
 through a FreeS/WAN box, as explained in our<A HREF="policygroups.html#policygroups">
 policy groups document</A>, or disable OE using<A HREF="policygroups.html#disable_policygroups">
 these instructions</A>.</P>
<H2><A name="extruded.config">Extruded Subnets</A></H2>
<P>What we call<A href="glossary.html#extruded"> extruded subnets</A>
 are a special case of<A href="glossary.html#VPN.gloss"> VPNs</A>.</P>
<P>If your buddy has some unused IP addresses, in his subnet far off at
 the other side of the Internet, he can loan them to you... provided
 that the connection between you and him is fast enough to carry all the
 traffic between your machines and the rest of the Internet. In effect,
 he &quot;extrudes&quot; a part of his address space over the network to you, with
 your Internet traffic appearing to originate from behind his Internet
 gateway.</P>
<P>As far as the Internet is concerned, your new extruded net is behind
 your buddy's gateway. You route all your packets for the Internet at
 large out his gateway, and receive return packets the same way. You
 route your local packets locally.</P>
<P>Suppose your friend has a.b.c.0/24 and wants to give you
 a.b.c.240/28. The initial situation is:</P>
<PRE>    subnet           gateway          Internet
  a.b.c.0/24    a.b.c.1    p.q.r.s</PRE>
 where anything from the Internet destined for any machine in a.b.c.0/24
 is routed via p.q.r.s and that gateway knows what to do from there.
<P>Of course it is quite normal for various smaller subnets to exist
 behind your friend's gateway. For example, your friend's company might
 have a.b.c.16/28=development, a.b.c.32/28=marketing and so on. The
 Internet neither knows not cares about this; it just delivers packets
 to the p.q.r.s and lets the gateway do whatever needs to be done from
 there.</P>
<P>What we want to do is take a subnet, perhaps a.b.c.240/28, out of
 your friend's physical location<EM> while still having your friend's
 gateway route to it</EM>. As far as the Internet is concerned, you
 remain behind that gateway.</P>
<PRE>    subnet           gateway          Internet       your gate  extruded

  a.b.c.0/24   a.b.c.1     p.q.r.s              d.e.f.g         a.b.c.240/28                

                           ========== tunnel ==========</PRE>
<P>The extruded addresses have to be a complete subnet.</P>
<P>In our example, the friend's security gateway is also his Internet
 gateway, but this is not necessary. As long as all traffic from the
 Internet to his addresses passes through the Internet gate, the
 security gate could be a machine behind that. The IG would need to
 route all traffic for the extruded subnet to the SG, and the SG could
 handle the rest.</P>
<P>First, configure your subnet using the extruded addresses. Your
 security gateway's interface to your subnet needs to have an extruded
 address (possibly using a Linux<A href="glossary.html#virtual"> virtual
 interface</A>, if it also has to have a different address). Your
 gateway needs to have a route to the extruded subnet, pointing to that
 interface. The other machines at your site need to have addresses in
 that subnet, and default routes pointing to your gateway.</P>
<P>If any of your friend's machines need to talk to the extruded subnet,<EM>
 they</EM> need to have a route for the extruded subnet, pointing at his
 gateway.</P>
<P>Then set up an IPsec subnet-to-subnet tunnel between your gateway and
 his, with your subnet specified as the extruded subnet, and his subnet
 specified as &quot;0.0.0.0/0&quot;.</P>
<P>The tunnel description should be:</P>
<PRE>conn extruded
        left=p.q.r.s
        leftsubnet=0.0.0.0/0
        right=d.e.f.g
        rightsubnet=a.b.c.0/28</PRE>
<P>If either side was doing firewalling for the extruded subnet before
 the IPsec connection is set up, you'll need to poke holes in your<A HREF="firewall.html#firewall">
 firewall</A> to allow packets through.</P>
<P>And it all just works. Your SG routes traffic for 0.0.0.0/0 -- that
 is, the whole Internet -- through the tunnel to his SG, which then
 sends it onward as if it came from his subnet. When traffic for the
 extruded subnet arrives at his SG, it gets sent through the tunnel to
 your SG, which passes it to the right machine.</P>
<P>Remember that when ipsec_manual or ipsec_auto takes a connection
 down, it<EM> does not undo the route</EM> it made for that connection.
 This lets you take a connection down and bring up a new one, or a
 modified version of the old one, without having to rebuild the route it
 uses and without any risk of packets which should use IPsec
 accidentally going out in the clear. Because the route always points
 into KLIPS, the packets will always go there. Because KLIPS temporarily
 has no idea what to do with them (no eroute for them), they will be
 discarded.</P>
<P>If you<EM> do</EM> want to take the route down, this is what the
 &quot;unroute&quot; operation in manual and auto is for. Just do an unroute after
 doing the down.</P>
<P>Note that the route for a connection may have replaced an existing
 non-IPsec route. Nothing in Linux FreeS/WAN will put that pre-IPsec
 route back. If you need it back, you have to create it with the route
 command.</P>
<H2><A name="roadvirt">Road Warrior with virtual IP address</A></H2>
<P>Please note that<A HREF="http://www.freeswan.ca/download.php"> Super
 FreeS/WAN</A> now features DHCP-over-IPsec, which is an alternate
 procedure for Virtual IP address assignment.</P>
<P></P>
<P>Here is a mailing list message about another way to configure for
 road warrior support:</P>
<PRE>Subject: Re: linux-ipsec: understanding the vpn
   Date: Thu, 28 Oct 1999 10:43:22 -0400
   From: Irving Reid &lt;irving@nevex.com&gt;

&gt;  local-------linux------internet------mobile
&gt;  LAN        box                         user
&gt;  ...

&gt;  now when the mobile user connects to the linux box
&gt;  it is given a virtual IP address, i have configured it to
&gt;  be in the 10.x.x.x range. mobile user and linux box 
&gt;  have a tunnel between them with these IP addresses.

&gt;   Uptil this all is fine.

If it is possible to configure your mobile client software *not* to
use a virtual IP address, that will make your life easier. It is easier
to configure FreeS/WAN to use the actual address the mobile user gets
from its ISP.

Unfortunately, some Windows clients don't let you choose.

&gt;  what i would like to know is that how does the mobile
&gt;  user communicate with other computers on the local
&gt;  LAN , of course with the vpn ?

&gt;   what IP address should the local LAN 
&gt;  computers have ? I guess their default gateway 
&gt;  should be the linux box ? and does the linux box need
&gt;  to be a 2 NIC card box or one is fine.

As someone else stated, yes, the Linux box would usually be the default
IP gateway for the local lan.

However...

If you mobile user has software that *must* use a virtual IP address,
the whole picture changes. Nobody has put much effort into getting
FreeS/WAN to play well in this environment, but here's a sketch of one
approach:

Local Lan 1.0.0.0/24
    |
    +- Linux FreeS/WAN 1.0.0.2
    |
    | 1.0.0.1
 Router
    | 2.0.0.1
    |
Internet
    |
    | 3.0.0.1
Mobile User
      Virtual Address: 1.0.0.3

Note that the Local Lan network (1.0.0.x) can be registered, routable
addresses.

Now, the Mobile User sets up an IPSec security association with the
Linux box (1.0.0.2); it should ESP encapsulate all traffic to the
network 1.0.0.x **EXCEPT** UDP port 500. 500/udp is required for the key
negotiation, which needs to work outside of the IPSec tunnel.

On the Linux side, there's a bunch of stuff you need to do by hand (for
now). FreeS/WAN should correctly handle setting up the IPSec SA and
routes, but I haven't tested it so this may not work...

The FreeS/WAN conn should look like:

conn mobile
        right=1.0.0.2
        rightsubnet=1.0.0.0/24
        rightnexthop=1.0.0.1
        left=0.0.0.0  # The infamous &quot;road warrior&quot;
        leftsubnet=1.0.0.3/32

Note that the left subnet contains *only* the remote host's virtual
address.

Hopefully the routing table on the FreeS/WAN box ends up looking like
this:

% netstat -rn
Kernel IP routing table
Destination     Gateway      Genmask         Flags   MSS Window  irtt Iface
1.0.0.0         0.0.0.0      255.255.255.0   U      1500 0          0 eth0
127.0.0.0       0.0.0.0      255.0.0.0       U      3584 0          0 lo
0.0.0.0         1.0.0.1      0.0.0.0         UG     1500 0          0 eth0
1.0.0.3         1.0.0.1      255.255.255.255 UG     1433 0          0 ipsec0

So, if anybody sends a packet for 1.0.0.3 to the Linux box, it should
get bundled up and sent through the tunnel. To get the packets for
1.0.0.3 to the Linux box in the first place, you need to use &quot;proxy
ARP&quot;.

How this works is: when a host or router on the local Ethernet segment
wants to send a packet to 1.0.0.3, it sends out an Ethernet level
broadcast &quot;ARP request&quot;. If 1.0.0.3 was on the local LAN, it would
reply, saying &quot;send IP packets for 1.0.0.3 to my Ethernet address&quot;.

Instead, you need to set up the Linux box so that _it_ answers ARP
requests for 1.0.0.3, even though that isn't its IP address. That
convinces everyone else on the lan to send 1.0.0.3 packets to the Linux
box, where the usual FreeS/WAN processing and routing take over.

% arp -i eth0 -s 1.0.0.3 -D eth0 pub

This says, if you see an ARP request on interface eth0 asking for
1.0.0.3, respond with the Ethernet address of interface eth0.

Now, as I said at the very beginning, if it is *at all* possible to
configure your client *not* to use the virtual IP address, you can avoid
this whole mess.</PRE>
<H2><A name="dynamic">Dynamic Network Interfaces</A></H2>
<P>Sometimes you have to cope with a situation where the network
 interface(s) aren't all there at boot. The common example is notebooks
 with PCMCIA.</P>
<H3><A name="basicdyn">Basics</A></H3>
<P>The key issue here is that the<VAR> config setup</VAR> section of the<VAR>
 /etc/ipsec.conf</VAR> configuration file lists the connection between
 ipsecN and hardware interfaces, in the<VAR> interfaces=</VAR> variable.
 At any time when<VAR> ipsec setup start</VAR> or<VAR> ipsec setup
 restart</VAR> is run this variable<STRONG> must</STRONG> correspond to
 the current real situation. More precisely, it<STRONG> must not</STRONG>
 mention any hardware interfaces which don't currently exist. The
 difficulty is that an<VAR> ipsec setup start</VAR> command is normally
 run at boot time so interfaces that are not up then are mis-handled.</P>
<H3><A name="bootdyn">Boot Time</A></H3>
<P>Normally, an<VAR> ipsec setup start</VAR> is run at boot time.
 However, if the hardware situation at boot time is uncertain, one of
 two things must be done.</P>
<UL>
<LI>One possibility is simply not to have IPsec brought up at boot time.
 To do this:
<PRE>        chkconfig --level 2345 ipsec off</PRE>
 That's for modern Red Hats or other Linuxes with chkconfig. Systems
 which lack this will require fiddling with symlinks in /etc/rc.d/rc?.d
 or the equivalent.</LI>
<LI>Another possibility is to bring IPsec up with no interfaces, which
 is less aesthetically satisfying but simpler. Just put
<PRE>        interfaces=</PRE>
 in the configuration file. KLIPS and Pluto will be started, but won't
 do anything.</LI>
</UL>
<H3><A name="changedyn">Change Time</A></H3>
<P>When the hardware *is* in place, IPsec has to be made aware of it.
 Someday there may be a nice way to do this.</P>
<P>Right now, the way to do it is to fix the<VAR> /etc/ipsec.conf</VAR>
 file appropriately, so<VAR> interfaces</VAR> reflects the new
 situation, and then restart the IPsec subsystem. This does break any
 existing IPsec connections.</P>
<P>If IPsec wasn't brought up at boot time, do</P>
<PRE>        ipsec setup start</PRE>
 while if it was, do
<PRE>        ipsec setup restart</PRE>
 which won't be as quick.
<P>If some of the hardware is to be taken out, before doing that, amend
 the configuration file so interfaces no longer includes it, and do</P>
<PRE>        ipsec setup restart</PRE>
<P>Again, this breaks any existing connections.</P>
<H2><A name="unencrypted">Unencrypted tunnels</A></H2>
<P>Sometimes you might want to create a tunnel without encryption. Often
 this is a bad idea, even if you have some data which need not be
 private. See this<A href="ipsec.html#traffic.resist"> discussion</A>.</P>
<P>The IPsec protocols provide two ways to do build such tunnels:</P>
<DL>
<DT>using ESP with null encryption</DT>
<DD>not supported by FreeS/WAN</DD>
<DT>using<A href="glossary.html#AH"> AH</A> without<A href="glossary.html#ESP">
 ESP</A></DT>
<DD>supported for manually keyed connections</DD>
<DD>possible with explicit commands via<A href="manpage.d/ipsec_whack.8.html">
 ipsec_whack(8)</A> (see this<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00190.html">
 list message</A>)</DD>
<DD>not supported in the<A href="manpage.d/ipsec_auto.8.html">
 ipsec_auto(8)</A> scripts.</DD>
</DL>
 One situation in which this comes up is when otherwise some data would
 be encrypted twice. Alice wants a secure tunnel from her machine to
 Bob's. Since she's behind one security gateway and he's behind another,
 part of the tunnel that they build passes through the tunnel that their
 site admins have built between the gateways. All of Alice and Bob's
 messages are encrypted twice.
<P>There are several ways to handle this.</P>
<UL>
<LI>Just accept the overhead of double encryption. The site admins might
 choose this if any of the following apply:
<UL>
<LI>policy says encrypt everything (usually, it should)</LI>
<LI>they don't entirely trust Alice and Bob (usually, if they don't have
 to, they shouldn't)</LI>
<LI>if they don't feel the saved cycles are worth the time they'd need
 to build a non-encrypted tunnel for Alice and Bob's packets (often,
 they aren't)</LI>
</UL>
</LI>
<LI>Use a plain IP-in-IP tunnel. These are not well documented. A good
 starting point is in the Linux kernel source tree, in
 /usr/src/linux/drivers/net/README.tunnel.</LI>
<LI>Use a manually-keyed AH-only tunnel.</LI>
</UL>
<P>Note that if Alice and Bob want end-to-end security, they must build
 a tunnel end-to-end between their machines or use some other end-to-end
 tool such as PGP or SSL that suits their data. The only question is
 whether the admins build some special unencrypted tunnel for those
 already-encrypted packets.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="kernel.html">Previous</A>
<A HREF="install.html">Next</A>
</BODY>
</HTML>
